Electronic devices such as controllers often run a conventional operating system (“OS”), such as Windows® or Linux®, or a multitasking or multithreading OS. In some cases, electronic devices may be used to model a set of computations being performed, or process a set of data, on a single computational element. However, the scheduling associated with this behavior introduces a considerable degree of uncertainty in the response time when measuring or capturing external stimuli in real-time.
A real-time data acquisition system conforms to very precisely timed behavior. In general, data samples are taken of some external signal at precisely timed intervals. Data may be transmitted between devices in units, such as individual samples of data, “words” or “records” consisting of multiple units of samples (for example, one sample for each channel of a data acquisition device at a single point in time), frames or blocks of data consisting of multiple words or records, or packets of data consisting of multiple frames. One having ordinary skill in the art will recognize that data may be sent in units of other sizes and configurations as well.
When a real time data acquisition system is used in conjunction with a conventional non-real time OS, a boundary exists between the real-time nature of the data acquisition system and the non-real time nature of the OS. That is, data is collected in real-time, but processed in non-real time, for example in a task-oriented device. The point at which a unit of data transitions from a real-time environment to a non-real time environment constitutes a boundary. The acquired data must cross this boundary, but as the data crosses the boundary, several problems may occur. For example, data may be lost, delayed, or be placed out-of-sequence as it crosses the boundary. Such a boundary 102 is depicted in FIG. 1 and will be described in more detail below.
One conventional methodology associated with real-time data acquisition and processing utilizes a custom-designed and application-specific real-time system for both data acquisition and processing. In this methodology, a custom-designed real-time information management system is generally employed. A real-time data acquisition device streams data to the real-time information management system; thus, there is no real-time/non-real-time boundary to cross. A drawback to this approach is that such a system is designed for a specific application, and is not suited to other applications or another data acquisition device. For example, a custom-built real-time information management system for a conventional Electroencephalography (EEG) device may only be suited to process EEG signals, and may not be suited to another application. Therefore, this methodology describes a point solution, and not a general-purpose system.
A second methodology, depicted in FIG. 1, provides for some flexibility in the way the system is employed. In this system, data acquisition device 110 acquires data in real time. A general-purpose non-real time OS 132 is stored in memory 130 of computing device 160. The OS requests data 120 from the data acquisition device 110, and the data acquisition device provides the requested data 170. The processor 140 processes the data 170 and may render it on a display 150.
However, this solution has several drawbacks as well. For example, because the non-real time OS requests data from the acquisition device 110, and because the OS is a task-oriented rather than a real-time system, some of the data acquired by the acquisition device 110 may not be requested, and may therefore not be sent or may be sent in a delayed fashion. This problem may be compounded by the fact that the OS must share the limited resources of the computing system 100 among several tasks, including processing, saving, and displaying the data. If the processor 140 is busy on other tasks, or if processing one unit of the acquired data takes longer than expected, then the OS may be delayed from requesting 120 the next unit of data. Systems like this do not operate in real time, but rather with a delay. As a result of these problems, systems such as the one depicted in FIG. 1 are prone to issues of data integrity, to delay in reporting and displaying data acquired in real time, and lack determinism.
Another problem associated with data acquisition and processing systems is known as “jitter.” Jitter is a time variation of a characteristic in a signal, and is sometimes referred to as noise. Jitter is an undesirable factor in signal processing because it may reduce the accuracy of a result; however, jitter is unavoidable in many cases.
Thus, there is a need for general purpose system that is capable of acquiring data in a real-time manner and subsequently streaming the data across the boundary between the real-time device and a non-real time device, and to do so for an arbitrary amount of time. Further, the system can operate with determinism and without introducing data integrity issues into the data stream and reduce the errors associated with jitter.